The compiled .parameters.json file created from a .bicepparam input is never deleted, unlike the generated ARM template which is cleaned up later. This can leave artifacts next to the user’s parameters file (and can dirty a repo working tree). Track whether compilation happened and remove the compiled file at the end (or write it to a temp file and clean up via defer).

Done. Refactored to os.CreateTemp so the compiled JSON goes to a temp path instead of next to the user's .bicepparam file, and added a defer that removes it (with a warning on cleanup error). The compile logic is now in a small helper, bicepUtils.CompileBicepParamsToTempFile, which also handles error cleanup so the temp file isn't left behind on failure.

Markdown formatting is broken here: the PowerShell code block is not properly closed before the next heading (the closing fence and heading are on the same line). This will render incorrectly in the docs; put the closing ``` on its own line, then add the heading on the next line.

Fixed. Moved the closing fence to its own line and put a blank line before the next heading so the markdown renders correctly.

This PowerShell example command has an extra dot in the executable path (.\.azmpf.exe). It should match the earlier examples (e.g., ./azmpf on bash, .\azmpf.exe on Windows) so users can copy/paste successfully.

Fixed — .\.azmpf.exe was a typo, it's now .\azmpf.exe to match the other examples and so it can be copy/pasted directly.

The errors from getAbsolutePath are ignored here. If path resolution fails, the test will proceed with a bad path and fail later with a less actionable error. Handle the error and fail/skip the test accordingly.

Done. Both getAbsolutePath calls now check the error and t.Fatalf with a descriptive message instead of silently continuing with a possibly-bogus path.

This test compiles the .bicepparam file manually and passes the compiled JSON into MPF, so it doesn’t actually exercise the new behavior added in cmd/bicepCmd.go (auto-detect + compile when --parametersFilePath ends with .bicepparam). Consider adding a CLI-level e2e that runs azmpf bicep --parametersFilePath <.bicepparam> (or factoring the compilation logic into a testable helper) to verify the intended user-facing path.

Good point. I extracted the compile logic out of cmd/bicepCmd.go into pkg/infrastructure/bicepUtils (IsBicepParamFile + CompileBicepParamsToTempFile). The CLI now calls the helper, and the e2e test calls the same helper instead of doing its own bicep build-params invocation, so the test exercises the actual user-facing code path. Also added a small unit test for IsBicepParamFile.

If bicep build fails, the test logs/t.Errorf but continues, which can lead to follow-on failures (missing template file) that obscure the root cause. Use t.Fatal/t.Fatalf here to stop the test when the build fails.

Done. Switched to t.Fatalf (with the bicep build output included) so a build failure stops the test immediately instead of cascading into a missing-template error later.

armTemplatePath is generated during the test but never removed. Add a t.Cleanup (or defer) to delete it to avoid leaving artifacts under samples/ and to prevent interference across repeated e2e runs.

Done. Added t.Cleanup(func() { _ = os.Remove(armTemplatePath) }) right after computing the path so the generated .json is removed even if the test fails or panics.

Silent overwrite of existing file

compiledParamsPath is derived deterministically as <name>.parameters.json next to the original .bicepparam file. If a file with that name already exists (e.g. the user already has a storage-account-simple-params.parameters.json), it is silently overwritten without warning. Consider checking for file existence first and erroring out .

Addressed. The compiled parameters file now goes to os.CreateTemp("", "mpf-bicepparam-*.parameters.json") instead of being placed next to the source file, so any pre-existing <name>.parameters.json the user has is left untouched. The compiled file is removed via defer when MPF exits.

Assertion too weak — we need to use exact permission count

If there a good reason not to do so then we need to mention it.

assert.GreaterOrEqual(..., 4) is imprecise. The PR comment above lists exactly 4 expected permissions, so the exact count is known. The existing TestBicepAksFullDeployment uses assert.Equal(t, 9, ...) for the same reason — an exact count catches regressions that a lower-bound check misses. Please use assert.Equal(t, 4, ...) to stay consistent and make the test deterministic.

Thanks

Done. Switched to assert.Equal(t, 4, len(...)) to match the established pattern in TestBicepAksFullDeployment and to actually catch regressions in the permission count.